In mobile communication networks, there is always a challenge to obtain good performance and capacity for a given communications protocol, its parameters and the physical environment in which the mobile communication network is deployed.
Existing real-time audio-visual communication services, including the 3GPP (3rd Generation Partnership Project) technical standard TS 26.114 (MTSI; Multimedia Telephony Service for Internet Protocol Multimedia Subsystem) and the profile called IR.94 in GSMA (the Global System for Mobile Communications Association), use SIP/SDP (Session Initiation Protocol/Session Description Protocol) as signaling to configure and setup a call between two user equipment (UE), and use the Internet Protocol (IP), the User Datagram Protocol (UDP) and the Real-time Transport Protocol (RTP) to encapsulate a (compressed representation of) media data during transport, on top of any chosen physical transport medium.
SDP (and extensions to SDP) defines bitrate parameters, applicable per media or for the entire media aggregate included in a session. SDP is typically sent once during session setup, and occasionally also mid-session. The IMS system uses information from the SDP to map different media streams to different quality radio bearers, where the quality is typically parameterized into a set of parameters that does not include bitrate, but instead uses information from SDP and pre-configured rules to establish a maximum bitrate limit, a minimum guaranteed bitrate limit and possibly also a minimum bitrate limit.
The RTP control protocol (RTCP) is typically used to convey information from media receiver to media sender (e.g., from one UE to another UE or from a media server to a UE) of transport characteristics, like bitrate, loss and delay as seen by the media receiver. A temporary shortage of available transport bitrate compared to what bitrate was produced at the media sender typically impacts other media characteristics listed in the RTCP, which can then be used by the media sender to both detect that there is a shortage and, more or less accurately, dynamically estimate the magnitude of this shortage.
As a complement to the above, there is also an RTCP extension, defined in Codec Control Messages (CCM), which allows a media receiver's opinion of a maximum bitrate to be explicitly communicated to the media sender in a TMMBR (Temporary Maximum Media Stream Bit Rate Request) message. This allows the media receiver to communicate its' opinion of the magnitude of the bitrate shortage to the media sender.
Media senders that are able to impact the produced media bitrate in 3GPP MTSI and VoLTE (Voice over Long Term Evolutional) are mainly the UE, but may also include network nodes in other parts of the network, such as for example, the Media Resource Function Processor (MRFP) or Session Border Gateways (SBG).
The bitrate parameter exchanged in SDP for a specific session only establishes a maximum allowable bitrate that a media sender can use. In some cases, when the media sender also has information about radio layer signaling, it may know the guaranteed minimum bitrate lower limit, if such limit exists (may be 0). This minimum bitrate is however not guaranteed at all times, but only to a certain level of significance. Even in the best case, there are thus only a minimum and a maximum limit and actually available bitrate at a certain point in time may be anywhere between those values.
For the case of RTCP information, it may be desirable to limit the network resources taken by the transmission of RTCP transport characteristics observations, since it may be preferred to put as much resources as possible to the (RTP) media itself. Therefore, the media receiver may aggregate data for some time and report a summary valid for some period of time, creating both a delay in conveying the information and a loss of accuracy due to the aggregation.
Since the reported RTCP data is based on observations of the received media rather than actual first-hand network resource information, information accuracy on network resources is lost also in this step. The media characteristics that can be observed at the receiver include both local media sender choices and actions impacting media transmission as well as characteristics caused by the actual transport channel. Typically, the media receiver is not aware of what parts of the characteristics that were present as a more or less conscious choice already at the sender, and what parts that were impacted by the transport. Some media sender characteristics information is available in RTCP messages sent from the media sender to the media receiver, but information therein may not be enough to exactly know what was caused by the transport and what was not.
Regarding the explicit maximum bitrate value in the TMMBR message, the information source of that value is left open in the specification. If the information elements used to set the TMMBR bitrate are exactly the same as sent in the RTCP messages, it may be possible that the receiver of those RTCP messages is able to arrive at the same TMMBR bitrate, and sending TMMBR thus becomes redundant.
In conclusion, the above disclosed methods to estimate available bitrate makes it hard to accurately match actually available bitrate resources to the produced bitrate at the media sender, leading to bad QoE, such as for example one or more of lower-than-necessary media quality due to under-utilization of available bitrate resources, loss of media data due to over-use of bitrate resources, delay and delay variation due to (long or short-term) over-use of bitrate resources.
Thus, accurate and timely bitrate information is not available from the two currently available sources; SDP or RTCP feedback.
Hence, there is still a need for improved bitrate information in communication networks.